src: detach cppgc wrappers from their Realm before it is freed - #65778
Open
codebytere wants to merge 1 commit into
Open
src: detach cppgc wrappers from their Realm before it is freed#65778codebytere wants to merge 1 commit into
codebytere wants to merge 1 commit into
Conversation
Collaborator
|
Review requested:
|
Collaborator
`Realm::RunCleanup()` finalizes the cppgc-managed wrappers it tracks so that none of them touches the Realm once it is gone, but it reaches them through weak persistents, and the GC clears those as soon as it finds a wrapper dead. With lazy and concurrent sweeping the destructor can run much later, so a wrapper collected shortly before `FreeEnvironment()` and swept after it was skipped by the cleanup and kept its `realm_`: `~CppgcMixin()` then wrote `should_purge_empty_cppgc_wrappers_` into the freed Realm, and a subclass destructor calling `Finalize()` as documented would have called `Clean()` with a dangling Realm. A Worker that compiles a few `vm.Script`s, gets a full GC from external memory pressure and calls `process.exit()` is enough to hit the first case. Move the Realm pointer into the list node, which the wrapper now owns and deletes in its destructor. `CppgcWrapperList::Cleanup()` unlinks every node, finalizing the wrappers that are still alive and clearing the Realm pointer for the collected ones, which only their own destructor may still touch. `Realm::PendingCleanup()` accounts for the list so it is always drained. The purge flag, its GC epilogue callback and `PurgeEmpty()` are no longer needed, and removing them also stops the list nodes of wrappers that are alive at `FreeEnvironment()` from leaking. Refs: nodejs#56534 Signed-off-by: Shelley Vohr <[email protected]>
codebytere
force-pushed
the
fix/embedder-cppgc-wrapper-realm-lifetime
branch
from
September 4, 2026 08:45
bbc133a to
6bb6296
Compare
Collaborator
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #65778 +/- ##
==========================================
+ Coverage 89.99% 90.05% +0.05%
==========================================
Files 757 769 +12
Lines 257739 261377 +3638
Branches 48881 49629 +748
==========================================
+ Hits 231961 235377 +3416
- Misses 16861 17033 +172
- Partials 8917 8967 +50
🚀 New features to boost your workflow:
|
Collaborator
Draft
2 tasks
Collaborator
Collaborator
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A
vm.Script(or any other cppgc-managed wrapper) that is garbage-collected shortly before its Environment is freed, but whose destructor only runs afterwards, writes into the already-freed Realm from~CppgcMixin(). With a stocknodebinary this happens in a Worker that compiles a few scripts, gets a full GC from external memory pressure and then callsprocess.exit(): ASAN reports a heap-use-after-free write in~ContextifyScriptwhile the Worker's isolate is being disposed. Embedders that free Environments on a long-lived isolate (Electron renderers) hit it during a later sweep instead.Realm::RunCleanup()is meant to detach every tracked wrapper from the Realm before the Realm goes away, but it reaches the wrappers through weak persistents. V8 clears those as soon as marking finds a wrapper dead, while the destructor runs later during lazy or concurrent sweeping, so wrappers in that window are skipped and keep their Realm pointer. A subclass using the documented~MyWrap() { Finalize(); }pattern would callClean()with a dangling Realm the same way.Once V8 has found a wrapper dead, nothing but its own destructor may touch it, so the fix moves the Realm pointer out of the wrapper and into the off-heap list node, which the wrapper now owns and frees in its destructor. Realm cleanup pops every node, finalizes the wrappers that are still alive and clears the Realm pointer on all of them; a collected wrapper's destructor then finds no Realm rather than a freed one.
Realm::PendingCleanup()counts the wrapper list as well so cleanup always drains it. The purge flag, its GC epilogue callback andPurgeEmpty()are no longer needed and are removed, which also stops the list nodes of wrappers still alive atFreeEnvironment()from leaking.Tests, in
test/cctest/test_cppgc.cc:CppgcTest.VmScriptCollectedBeforeFreeEnvironmentSweptAfter: the scenario above; heap-use-after-free under ASAN before the change.CppgcTest.CleanIsNotCalledWithFreedRealm: a wrapper using theFinalize()/Clean()pattern; fails before the change (every run under ASAN, roughly one run in three in a regular build, depending on whether the sweeper got there first).CppgcTest.WrappersAliveAtFreeEnvironmentDoNotLeak: reported by LSAN before the change.Refs: #56534
Disclosure: the code, tests and this description were written by Claude Code, directed and reviewed by @codebytere.